home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: schwarz@mips.complang.tuwien.ac.at (Konrad Schwarz)
- Newsgroups: comp.lang.c,comp.lang.c.moderated,hp.unix,comp.sys.hp.apps,comp.sys.hp.hpux
- Subject: Re: C coding problem
- Date: 4 Apr 1996 18:29:36 -0600
- Organization: TU Wien
- Sender: clc@solutions.solon.com
- Approved: clc@solutions.solon.com
- Message-ID: <4k1phg$4sv@solutions.solon.com>
- References: <4ianbf$h86@solutions.solon.com> <4iemcl$a05@solutions.solon.com> <4io1io$no4@solutions.solon.com> <4j41ru$nq4@solutions.solon.com> <4jttlq$3p1@solutions.solon.com> <4jv77f$cu8@solutions.solon.com>
- NNTP-Posting-Host: solutions.solon.com
-
- In article <4jv77f$cu8@solutions.solon.com>, ferguson@col.hp.com (Scott Ferguson) writes:
- |> I would hope by now that HP's C compiler has a fairly good degree of
- |> optimization built in, to the point that most cases of this:
-
- [pointer addressing vs. array indexing]
-
- |> In my former life, I worked on supercomputers, and the ONLY way to get
- |> decent performance out of C code was to use arrays whenever possible,
- |> otherwise the compiler which was built to maximize use of available
- |> hardware acceleration could tell what you were trying to do. So where
- |> do our compilers stand on this? If PA-RISC has some superscalar ops like
- |> multiply-add in a single clock, I'd rather give the compiler enough high-level
- |> language to optimize to what's best for the hardware.
-
- As a matter of fact, HP-UX comes with a large library of vector subroutines,
- supposedly hand-tuned for speed. The Fortran compiler has a source-to-source
- transformer that tries to find loops that can be replaced with calls to the
- library.
-
- I think this is the way to go if you want high performance vector computing.
- Use BLAS or Fortran-90 vector constructs. Optimizers have a long way to go
- before they are as smart as humans.
-
- Konrad Schwarz
-